最近目前我的公司要做新的專案，
所以藉此需要一個新的專案來做自動化測試，
所以開始在思考一個好的自動化測試他的形狀該長甚麼樣子，
順便分享一下如果我這菜雞寫自動化測試我會怎麼去構思以及怎麼寫。
如果你有不同的想法也歡迎在底下留言跟我交流~

注意~ 這篇主要會以 Web UI 的 E2E 測試為主要測試範例，
API 等測試可能會有些許不同。

我這邊以我自身經驗和思考過後覺得它會長以下這樣

feature

這邊這部份很單純是用來放測試很純粹的測試，
不管你是用 robot framework 還是 nigtwatch，
你都不應該把連續的步驟一個一個寫進去測試裡面你應該保持測試是乾淨的，
比方說今天要測試一個簡單的登入想必步驟會是以下這樣。

1. 打開瀏覽器
2. 導向至登入頁面
3. 輸入帳號
4. 輸入密碼
5. 點擊登入
6. 驗證 (URL 或是相關的歡迎訊息)
7. 登出
8. 關閉瀏覽器

這樣寫有甚麼問題?

1. 沒辦法直接看出來測試的目的
2. 在其他相似的測試沒辦法重複利用
3. 測試的時間拉長

看上面的步驟，
其實對於測試來說最重要的檢查點在於點擊登入這個動作後所出現的結果，
在前面的打開瀏覽器或導向登入頁面甚麼的都算是前置的動作，
這時我們可以透過 test hook 的形式將前面的步驟都模組化成一個動作，
可能叫做打開瀏覽器並導向至頁面，
那有前置動作就一定會有個結尾要做的事，
簡單來說就是你前置動作的相反，
開瀏覽器相反就是把瀏覽器關掉，
登入相反就是登出。
那這邊聰明的你就會想把結尾也包起來，
這邊就是上面步驟的登出和關閉瀏覽器。
所以此時測試會長得像是這樣~

1. [Setup] 打開瀏覽器並導向至頁面
2. 輸入帳號
3. 輸入密碼
4. 點擊登入
5. 驗證 (URL 或是相關的歡迎訊息)
6. [Teardown] 登出並關閉瀏覽器

我們這邊可以看到步驟已經減少了兩步，
接著我們要思考點擊登入前面的必要動作是不是可以被重複利用，
如果要測一個網站那想必登入這動作就是必須的所以這邊我會將

• 輸入帳號
• 輸入密碼
• 點擊登入

都包成一包叫做登入，
這樣測試就會變成以下這樣。

1. [Setup] 打開瀏覽器並導向至頁面
2. 登入
3. 驗證 (URL 或是相關的歡迎訊息)
4. [Teardown] 登出並關閉瀏覽器

這樣就會看起來很乾淨~
而且你可以很清楚的看到測試的目的。

小總結:
測試應該保持乾淨將需要驗證前和驗證後的步驟拆分成乾淨，
拆分和包裝時記得思考一下能不能被重複利用。

command

剛剛介紹完 featue 之後會想說包裝起來的相關的動作要放在哪?
就是這裡~

不管你做的連續動作是不是 UI 上面的操作，
只要是能被重複利用且清楚表達這些動作的目的你都應該要包起來放在這兒。
當你想寫一個新的測試時應該要先尋找這邊是不是有寫好的相關步驟，
而不是一昧的...
寫啦!
直接寫了啦!
哪次不寫!

我自身的習慣會是很共通的我可能會放在一個檔案叫做 common，
其他各自頁面或是功能獨有的會放在各自的檔案。

lib

有時候我們操作一些 selenium 相關的動作沒辦法透過原生的方式進行，
或是你想透過 API 去完成一些事情減少測試在 UI 操作，
但卻不是測試本身所需要測試的動作。
比方說...
上面的登入的測試想必還有一個前提是註冊帳號，
那如果說我將註冊帳號這些動作都包裝起來放在前置動作會發生甚麼事情?

1. 他會大幅增加測試的時間
2. 增加測試的失敗機率而且不是測試本身該做的事情

你想想~
萬一註冊的 UI 有一些 bug 造成你這前置動作失敗導致測試失敗，
那這個測試要測的到底是註冊還是登入啊?

你可能會想說...
不是阿! 我包也包了不然還有甚麼辦法?
答案是... 你可以透過 API 的方式去完成這些事。

你可能又會想說講的好像 API 就不會失敗一樣，
對!沒錯 API 也有可能會因為改動而造成測試失敗，
但是相對從 UI 下手來說他有兩個優點

1. 他比 UI 快
2. API 的改動頻率正常來說比 UI 來的少

tests

我都在寫測試了...
為甚麼我還要寫測試的測試?
你有想過在你要求 RD 寫 unit test 的同時，
你自己做的 libary 或是一些邏輯處理是沒問題的嗎?
我以前從來沒有想過為了我自己測試寫測試，
導致以前很常發生一件事

我: 欸那個... 某某部分壞了然後我看他回傳的是....
開發: 我這邊都沒改欸... 我再查查 。

(過了半小時

我: 欸...我感到抱歉 QQ 是我這邊寫錯我剛剛改了... ，所以是我這邊的問題...
開發:

那這時候如果你有為了你的測試做測試的話你也不用擔心發生這些尷尬的事情了xDDD

(關於為了測試寫測試這部分有很大的爭議，這邊就不戰到底該不該寫，反正我是覺得該寫。)

page_object

這是一個 design pattern ，
主要的用意是將頁面相關的 element 跟程式做分離和統一控管，
如果你不這樣做的話你可能會看到你的步驟裡面充滿著 xpath 和 css 的 selector...
這時候萬一網頁中其中一個元素改動你就必須...
去找吧! 我灑落在各地的 selector !
而且還有可能會發生這個按鈕的定位有 xpath 和 css 和各種排列組合的出現，
這邊會主要除了管理 selector 的部分之外還會統一定單純一個步驟的動作
例如上面範例中的輸入帳號、輸入密碼、點擊登入都會在這邊做實作
所以 command 基本上就是將 page_object 所弄好的單一動作組成一個 combo 連擊的概念~

總結

看完之後你可能會想說...
欸不是阿你這架構可能會有@#$%$%&^$%#^的問題

我想說的是...
其實沒有一個架構是完美的，
只有最符合你團隊的架構 (幹話)

分享給可能在構思自動化測試架構的你~
我之後可能會再補 Robot Framework 的 template (X

感謝您的收看
我是快被 dotnet core 搞瘋的 Robin~
我們下次見

ps. 身為 QA 但是我好像第一次寫關於 QA 的文章 ...
我深感抱歉xDD